Using the General Intensional Programming System (GIPSY) for 
Evaluation of Higher-Order Intensional Logic (HOIL) 

Expressions 



The General Intensional Programming System (GIPSY) has been built around the Lucid fam- 
ily of intensional programming languages that rely on the higher-order intensional logic (HOIL) to 
provide context-oriented multidimensional reasoning of intensional expressions. HOIL combines 
functional programming with various intensional logics to allow explicit context expressions to be 
evaluated as first-class values that can be passed as parameters to functions and return as results 
with an appropriate set of operators defined on contexts. GIPSY's frameworks are implemented in 
Java as a collection of replaceable components for the compilers of various Lucid dialects and the 
demand-driven eductive evaluation engine that can run distributively. GIPSY provides support for 
hybrid programming models that couple intensional and imperative languages for a variety of needs. 
Explicit context expressions limit the scope of evaluation of math expressions (effectively a Lucid 
program is a mathematics or physics expression constrained by the context) in tensor physics, regular 
math in multiple dimensions, etc., and for cyberforensic reasoning as one of the use-cases of interest. 
Thus, GIPSY is a support testbed for HOIL-based languages some of which enable such reason- 
ing, as in formal cyberforensic case analysis with event reconstruction. In this paper we discuss the 
GIPSY architecture, its evaluation engine and example use-cases. 

Keywords: Intensional Programming, Higher-Order Intensional Logic (HOIL), Run-Time System, 
General Intensional Programming System (GIPSY), Multi-Tier Architecture, Peer-to-Peer Architec- 
ture 

1 Introduction 

The GIPSY project is an ongoing effort aiming at providing a flexible platform for the investigation on 
the intensional programming model as realized by the latest versions of the Lucid programming lan- 
guage |l3l|4l|4T]|2l|5l, a multidimensional context-aware language whose semantics is based on possible 
worlds semantics |[T2l[T3i . GIPSY provides an integrated framework for compiling programs written in 
theoretically all variants of Lucid, and even any language of intensional nature that can be translated into 
some kind of "generic Lucid" (e.g. GIPL ||25l|29l or TransLucid IISTUBBII ). 

Historically, the concept of GIPSY was conceived as a very modular collection of frameworks geared 
towards sustainable support for the intensional programming languages and embracing continuous iter- 
ative revision and development overcoming defects of an earlier GLU system ifTOl [TTl U| that did not 
survive for very long due to its inflexibility to extend to the newer dialects, and its unmaintainability 
defects Il25ll28l[30l . The GIPSY's design centered around the compiler framework (GIPC), the eduction 
execution engine (GEE), a.k.a the run-time execution environment, a sort of virtual machine for exe- 
cution of the intensional logic expressions, and the programming environment (RIPE). The former of 
the three is responsible to support multiple compilers in a similar compiler framework that all produce a 
consistent, well agreed on binary format, essentially a compiled GIPSY program, as a binary output. The 
second performs lazy demand-driven, potentially parallel/distributed evaluation of the compiled Lucid 
programs, or as we call them, GIPSY programs. 
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1.1 Eductive Model of Computation 

The first operational model for computing Lucid programs was designed independently by Cargill at the 
University of Waterloo and May at the University of Warwick, based directly on the formal semantics of 
Lucid, itself based on Kripke models and possible- worlds semantics lfT2l [T3l . This technique was later 
extended by Ostrum for the implementation of the Luthid interpreter ^23). Luthid being tangential to 
standard Lucid, its implementation model was later used as a basis to the design of the pLucid interpreter 
by Faustini and Wadge 161 . This program evaluation model is now called eduction and opens doors for 
distributed execution of such programs ||36ll39l[38l[T8l . 

The concept of eduction can be described as "tagged-token demand-driven dataflow" computing 
(whereupon Lucid influenced a popular media platform and language called PureData |[32l ). The central 
concept to this model of execution is the notion of generation, propagation, and consumption of demands 
and their resulting values. Lucid programs are declarative programs where every identifier is defined as 
a HOIL expression using other identifiers and an underlying algebra. An initial demand for the value of 
a certain identifier is generated, and the eduction engine, using the defining expression of this identifier, 
generates demands for the constituting identifiers of this expression, on which operators are applied 
in their embedding expressions. These demands in turn generate other demands, until some demands 
eventually evaluate to some values, which aie then propagated back in the chain of demands, operators 
are applied to compute expression values, until eventually the value of the initial demand is computed 
and returned. 

Lucid identifiers and expressions inherently vary in a multidimensional context space, i.e. any iden- 
tifier or expression can be evaluated in a multidimensional context, thus leading to have identifiers and 
expressions representing a set of values, one value for each possible context in which the identifier or 
expression can be evaluated. This is brining the notion of intensionality, where identifiers are defined 
by intensional expressions i.e. expressions whose evaluation varies in a multidimensional context space, 
which can then be constrained by a particular multidimensional context specification. Note that Lucid 
variables and expressions represent "dimensionally abstract" concepts, i.e. they do not explicitly men- 
tion their dimensionality. For example, Newton's Law of Universal Gravitation can be written literally 
in Lucid as: 

F = (G * ml * m2) / r * r; 

and can then be evaluated in different dimensional manifolds (i.e. n-dimensional spaces), keeping the 
same definition, but being evaluated in contexts varying in their dimensionality. For example, F can 
be evaluated in a one-dimensional space, yielding a single scalar, or in a three-dimensional manifold, 
yielding a three-dimensional vector. Note that a time dimension could also be added where, for example, 
the masses (ml and m2) and/or the distance between them (r) might be defined as to vary in time. In 
such a case, the expression would then inherently be varying in the time dimension, due to some of its 
constituents varying in this dimension. 

1.2 Intensional Logic and Programming 

Intensional programming, in the sense of the latest evolutions of Lucid, is a programming language 
paradigm based on the notion of declarative programming where the declarations are evaluated in an 
inherent multidimensional context space. The context space being in most cases infinite, intensional 
programs are evaluated using a lazy demand-driven model of execution that we introduced earlier - 
eduction ||6l, where the program identifiers are evaluated in a restricted context space, in fact, a point 
in space, where each demand is generated, propagated, computed and stored as an identifier-context 
pair fT4l. 

Many problem domains are intensional in nature, e.g. computation of differential and tensor equa- 
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tions ll25l . temporal computation and temporal databases ll24l |37]| . multidimensional signal process- 
ing m, context-driven computing f43l|, constraint programming [421, negotiation protocols ll42]| . auto- 
mated reasoning in cyberforensics [,21ll20l[r7l . multimedia and pattern recognition |fT9l| among others. 
The current mainstream programming languages are not well adapted for the natural expression of the 
intensional aspects of such problems, requiring the expression of the intensional nature of the problem 
statement into a procedural (and therefore sequential) approach in order to provide a computational so- 
lution. 

Intensional programming can be used to solve widely diversified problems, which can be expressed 
using diversified languages of intensional nature. There also has been a wide array of flavors of Lucid 
languages developed over the years. Yet, very few of these languages have made it to the implementation 
level. The GIPSY project aims at the creation of a programming environment encompassing compiler 
generation for all flavors of Lucid, a generic run-time system enabling the execution of programs written 
in all flavors of Lucid. Our goal is to provide a flexible platform for the investigation on programming 
languages of intensional nature, in order to prove the applicability of intensional programming to solve 
important problems. 

Intensional programming is based on intensional (or multidimensional) logics, which, in turn, are 
based on natural language understanding (aspects, such as, time, belief, situation, and direction are con- 
sidered). Intensional programming brings in dimensions and context to programs (e.g. space and time in 
physics or chemistry). Intensional logic adds dimensions to logical expressions; thus, a non-intensional 
logic can be seen as a constant or a snapshot in all possible dimensions. Intensions are dimensions at 
which a certain statement is true or false (or has some other than a Boolean value). Intensional operators 
are operators that allow us to navigate within these dimensions ll25l . 

1.2.1 Temporal Intensional Logic Example 

Temporal intensional logic is an extension of temporal logic that allows to specify the time in the future 
or in the past ll25ll . 

(1) £1 := it is raining here today 
Context: {place : here, time : today} 

(2) E2 := it was raining here fte/ore(today) = yesterday 

(3) £3 := it is going to rain at (altitude here -1- 500 m) a/fer( today) = tomorrow 

Let's take E\ from (1) above. The context is a collection of the dimensions place and time with the 
corresponding tag values of here and today. Then let us fix here to Montreal and assume it is a constant. 
In the month of May, 2009, with granularity of day, for every day, we can evaluate E\ to either true or 
false, as shown in Figure [T] If one starts varying the here dimension (which could even be broken down 



Tags days in May : 123456789... 
Values (raining?) : FFTTTFFFT... 



Figure 1: ID example of tag-value contextual pairs. 

to X, Y , Z), one gets a two-dimensional (or 4D respectively) evaluation of E\, as shown in Figure[2] Even 
with these toy examples we can immediately illustrate the hierarchical notion of the dimensions in the 
context: so far the place and time we treated as atomic values fixed at days and cities. In some cases, we 
need finer subdivisions of the context evaluation, where time can become fixed at hour, minute, second 
and finer values, and so is the place broken down into boroughs, regions, streets, etc. and finally the 
X,Y,Z coordinates in the Euclidean space with the values of millimeters or finer. This notion becomes 
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Place/Time 
Montreal 



TFTFTFTFT 



123456789 



Honolulu 
New York 
Tampa 



FFTTTFFFT 
FFFFTTTFF 



FTTTTTFFF 



Figure 2: 2D example of tag-value contextual pairs. 



more apparent and important e.g. in Forensic Lucid, a forensic case specification language for automated 
reasoning in cybercrime and other investigations. 



To summarize, expressions written in virtually all Lucid dialects are correspond to higher-order inten- 
sional logic (HOIL) expressions with some dialect-specific instantiations. They all can alter the context 
of their evaluation given a set of operators and in some cases types of contexts, their range, and so 
on. HOIL combines functional programming and intensional logics, e.g. temporal intensional logic 
mentioned earlier. The contextual expression can be passed as parameters and returned as results of a 
function and constitute the multi-dimensional constraint on the Lucid expression being evaluated. The 
corresponding context calculus B2l |29l |40l defines a comprehensive set of context operators, most of 
which are set operators and the baseline operators are and # that allow to switch the current context 
or query it, respectively. Other operators allow defined a context space and a point in that context corre- 
sponding to the current context. The context can be arbitrary large in its rank. The identified variables of 
the dimension type within the context can take on any data type, e.g. an integer, or a string, during lazy 
binding of the resulting context to a dimension identifier. 



GIPSY evolved from a modular collection of frameworks for local execution into a multi-tier architec- 
ture |[26l . With the bright but short-lived story of GLU in mind, efforts were made to design a new 
system with similar capacities, but with more flexibility in mind. The new system would have to be 
able to cope with the fast evolution and diversity of the Lucid family of languages, thus necessitating 
a flexible compiler architecture, and a language-independent run-time system for the execution of Lu- 
cid programs. The architecture of the GIPSY compiler, the General Intensional Programming Compiler 
(GIPC) is framework-based, allowing the modular development of compiler components (e.g. parser, 
semantic analyzer and translator). It is based on the notion of the Generic Intensional Programming 
Language (GIPL), a core language into which all other flavors of the Lucid language can be translated 
to. The notion of a generic language also solved the problem of language-independence of the run-time 
system by allowing a common representation for all compiled programs, the Generic Eduction Engine 
Resources (GEER), which is a dictionary of run-time resources compiled from a GIPL program, that had 
been previously generated from the original program using semantic translation rules defining how the 
original Lucid program can be translated into the GIPL. For a more complete description of the GIPSY 
compiler framework, see P31l34ll27l [l6l. The architecture necessitates the presence of the intensional- 
imperative type system and support links to imperative languages being presented elsewhere ll22l . 



1.3 HOIL 



2 GIPSY'S Architecture 
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2.1 General Intensional Program Compiler (GIPC) 

The GIPSY, conceptually represented at the high level in Figure [3] The type abstractions and imple- 
mentations are located in the gipsy . lang package and serve as a glue between the compiler (known as 
the GIPC - a General Intensional Program Compiler) and the run-time system (known as the GEE - a 
General Eduction Engine) to do the static and dynamic semantic analyses and evaluation respectively. 
The GIPSY is a very modular system allowing most components to be replaceable as long as they com- 
ply with some general architectural interface or API. One of such API interfaces is the GIPSYProgram 
(conceptually represented as GEER - GEE Resource - a dictionary of run-time resources) that contains 
among other things the type annotations that can be statically inferred during compilation. At run-time, 
the engine does it's own type checking and evaluation when traversing the AST stored in the GEER and 
evaluating expressions represented in the tree. Since both the GIPC and the GEE use the same type 
system to do their analysis, they consistently apply the semantics and rules of the type system with the 
only difference that the GEE, in addition to the type checks, does the actual evaluation. The GIPSY is 
primarily implemented in Java. 



jcidPeclaralinnsAST 



DemandGeneratorTier 



DemandSloraTler 



DemandWorkerTler 



Figure 3: GIPSY's GIPC-to-GEE GEER Flow Overview in Relation to the GIPSY Type System. 
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Figure 4: GIPC Framework 

The Preprocessor |[T6l [T5l is something that is invoked first by the GIPC (see Figure |4]) on in- 
coming GIPSY program's source code stream. The Preprocessor's role is to do prehminary program 
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analysis, processing, and splitting the source GIPSY program into "chunks", each written in a different 
language and identified by a language tag. In a very general view, a GIPSY program is a hybrid program 
consisting of different languages in one or more source file; then, there has to be an interface between 
all these code segments. Thus, the Preprocessor after some initial parsing (using its own preprocessor 
syntax) and producing the initial parse tree, constructs a preliminary dictionary of symbols used through- 
out the program. This is the basis for type matching and semantic analysis applied later on. This is also 
where the first step of type assignment occurs, especially on the boundary between typed and typeless 
parts of the program, e.g. Java and a specific Lucid dialect. The Preprocessor then splits the code seg- 
ments of the GIPSY program into chunks preparing them to be fed to the respective concrete compilers 
for those chunks. The chunks are represented through the CodeSegment class that the GIPC collects. 

2.2 General Eduction Engine (GEE) 

The design architecture adopted is a distributed multi-tier architecture, where each tier can have any 
number of instances. The architecture bears resemblance with a peer-to-peer architecture, e.g.: 

• Demands are propagated without knowing where they will be processed or stored. 

• Any tier or node can fail without the system to be fatally affected. 

• Nodes and tiers can seamlessly be added or removed on the fly as computation is happening. 

• Nodes and tiers can be affected at run-time to the execution of any GIPSY program, i.e. a specific 
node or tier could be computing demands for different programs. 

2.2,1 Generic Eduction Engine Resources 

One of the central concepts of our solution is language independence of the run-time system. In order 
to achieve that, we rely on an intermediate representation that is generated by the compiler: the Generic 
Eduction Engine Resources (GEER). The General Intensional Programming Compiler (GIPC) compiles 
a program into an instance of the GEER, a dictionary of identifiers compiled from the program by the 
compiler |[27l UM . The compiler framework provides with the potential to allow the easy addition of 
any flavor of the Lucid language to be added through automated compiler generation taking semantic 
translation rules in input |45|. As the name suggests, the GEER structure is generic, in the sense that the 
data structure and semantics of the GEER are independent of the language in which its corresponding 
source code was written. This is necessitated by the fact that the engine was designed to be "source 
language independent", an important feature made possible by the presence of the Generic Intensional 
Programming Language (GIPL) as a generic language in the Lucid family of languages. Thus, the 
compiler first translates the source program (written in any flavor of Lucid) into "generic Lucid", then 
generate the GEER run-time resources for this program, which is then made available at run-time to the 
various tiers upon demand. The GEER contains, for all Lucid identifiers in a given program, typing 
information, rank i.e. dimensionality information, as well as an abstract syntax tree representation of 
the declarative definition of the identifier. It is this latter tree that is later on traversed by the demand 
generator in order to proceed with demand generation. In the case of hybrid Lucid programs, the GEER 
also contains a dictionary of procedures called by the Lucid program, known as Procedure Classes, as 
they in fact are wrapper classes wrapping procedures inside a Java class in cases where the functions 
being called are not written in Java |[T6l[T5]| . 
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2.2.2 GIPSY Tier 

The architecture adopted for this new evolution of the GIPSY is a multi-tier architecture where the 
execution of GIPSY programs is divided in three different tasks assigned to separate tiers. Each GIPSY 
tier is a separate process that communicates with other tiers using demands, i.e. the GIPSY Multi-Tier 
Architecture operational mode is fully demand-driven. The demands are generated by the tiers and 
migrated to other tiers using the Demand Store Tier. In this paper, we refer to a "tier" as an abstract and 
generic entity that represents a computational unit independent of other tiers and that collaborates with 
other tiers to achieve program execution as a group. 



2.2.3 GIPSY Node 

Abstractly, a GIPSY node is a computer that has registered for the hosting of one or more GIPSY tier. 
GIPSY Nodes are registered through a GIPSY Manager instance. Technically, a GIPSY Node is a con- 
troller that wraps GIPSY Tier instances, and that is remotely reporting and being controlled by a GIPSY 
Manager. Operationally, a GIPSY Node hosts one tier Controller for each kind of tier (see Figure [5]l. 
The Tier Controller acts as a factory that will, upon necessity, create instances of this tier, which provide 
the concrete operational features of the tier in question. This model permits scalability of computation 
by allowing the creation of new tiers instances as existing tier instances get overloaded or lost. 
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Figure 5: Design of the GIPSY Node 



2.2.4 GIPSY Instance 

A GIPSY Instance is a set of interconnected GIPSY Tiers deployed on GIPSY Nodes executing GIPSY 
programs by sharing their respective GEER instances. A GIPSY Instance can be executing across dif- 
ferent GIPSY Nodes, and the same GIPSY Node may host GIPSY Tiers that a part of separate GIPSY 
Instances 



2.2.5 Demand Generator Tier 

The Demand Generator Tier (DGT) generates demands according to the program declarations and def- 
initions stored in one of the instances of GEER that it hosts. The demands generated by the Demand 
Generator Tier instance can be further processed by other Demand Generator Tiers instances (in the 
case of intensional demands) or Demand Worker Tier instances (in the case of procedural demands), 
the demands being migrated across tier instances through a Demand Store Tier instance. Each DGT 
instance hosts a set of GEER instances that corresponds to the Lucid programs it can process demands 
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for. A demand-driven mechanism allows the Demand Generator Tier to issue system demands requesting 
for additional GEER instances to be added to its GEER Pool, thus enabling DST instances to process 
demands for additional programs as they are executed on the GIPSY instances they belong to. 



2.2.6 Demand Store Tier 

The Demand Store Tier (DST) acts as a tier middleware in order to migrate demands between tiers. In 
addition to the migration of the demands and values across different tiers, the Demand Store Tier provide 
persistent storage of demands and their resulting values, thus achieving better processing performances 
by not having to re-compute the value of every demand every time it is re-generated after having been 
processed. From this latter perspective, it is equivalent to the historical notion of warehouse in the 
eduction model of computation. A centralized communication point or warehouse is likely to become 
an execution bottleneck. In order to avoid that, the Demand Store Tier uses a peer-to-peer architecture 
and mechanism to connect all Demand Store Tier instances in a given GIPSY instance. This allows any 
demand or its resulting value to be stored on any DST instance, but yet allows abstract querying for a 
specific demand value on any of the DST instances. If the demanded value is not found on the DST 
instance receiving the demand, it will contact its DST instance peers using a peer-to-peer mechanism. 
This mechanism allows to see the Demand Store abstractly as a single store that is, behind the scenes, a 
distributed one. 



2.2.7 Demand Worker Tier 

The Demand Worker Tier (DWT) processes procedural demands i.e. demands for the execution of 
functions or methods defined in a procedural language, which are only present in the case where hybrid 
intensional programs are being executed. The DGT and DWT duo is an evolution of the generator- 
worker architecture adopted in GLU ifTOl [TTI . It is through the operation of the DWT that increased 
granularity of computation is achieved. Similarly to the DGT, each DWT instance hosts a set of compiled 
procedures (Procedure Classes) that corresponds to the procedural demands it can process. A demand- 
driven mechanism allows the Demand Worker Tier to issue system demands requesting for additional 
Procedure Classes to be added to its Procedure Class Pool, thus achieving increasing capacities over 
time, on demand. 



2.2.8 GIPSY Instance Manager 

A GIPSY Instance Manager (GIM) is a component that enables the registration of GIPSY Nodes and 
Tiers, and to allocate them to the GIPSY Instances that it manages. The GIPSY Instance Manager inter- 
acts with the allocated tiers in order to determine if new tiers and/or nodes are necessary to be created, 
and issue demands to GIPSY Nodes to spawn new tier instances if need there be. In order to ease the 
node registration, the GIPSY Instance Manager tier can be implemented using a web interface, so that 
users can register nodes using a standard web browser, rather than requiring a client. GIPSY Instance 
Managers are peer-to-peer components, i.e. users can register a node through any GIPSY Instance Man- 
ager, which will then inform all the others of the presence of the new node, which will then be available 
for hosting new GIPSY Tiers at the request of any of the GIPSY Instance Managers currently running. 
The GIM uses system demands to communicate with Nodes and Tiers. 



8 



Using GIPSY for Evaluation of HOIL Expressions 



Mokhov and Paquet 



3 Context-Oriented Reasoning 

As mentioned earlier, the reasoning aspect of GIPSY is a particularity of a Lucid dialect rather than the 
architecture, and in this paper we look at it from the reasoning angle. The architecture is general enough 
to go beyond reasoning - in the essence it is an evaluation of intensional logic expressions. Now if 
those expressions form a language dialect, that helps us with reasoning, such as Forensic Lucid to reason 
about cybercrime incidents and claims. Some other Lucid dialects have less relevance in that regard, but 
still can be included into the system - such as Tensor Lucid for tensor fields evaluation of particles in 
plasma |[25l . reactive programming, multi-core processing ||3n[33l . software versioning, and others. 

3.1 Lucx 

Lucx Il44ll42ll is a fundamental extension of GIPL and the Lucid family as a whole that promotes the con- 
texts as first-class values thereby creating a "true" generic Lucid language. Wan in f44ll42l defined a new 
collection of set operators (e.g. union, intersection, box, etc.) on the multidimensional contexts, which 
will help with the multiple explanations of the evidential statements in forensic evaluation where the con- 
text sets are often defined as cross products (boxes), intersections, and unions. Its further specification, 
refinement, and implementation details are presented in B0l|29l . 

3.2 Operational Semantics for Reasoning about Lucid Expressions 

Here for convenience we provide the semantic rules of Indexical Lucid ||25ll (see Figure [6]l, Lucx H2]| 
(see Figure |7]l. 

3.3 Higher Order Context 

HOCs represent essentially nested contexts, e.g. as conceptually shown in Figure [8] modeling evidential 
statement for forensic specification evaluation. Such a context representation can be modeled as a tree 
in an 00 ontology or a context-set as in Lucx. The early notion and specification of nested context first 
appeared Swoboda's works |[36ll39l[38l . but there the evaluation has taken place only at the leaf context 
nodes. Another, more recent work on the configuration specification as a context in the intensional 
manner was the MARFL language |[T9l[T7ll . allowing evaluation at arbitrary nesting of the configuration 
context with some defaults in the intermediate and leaf context nodes. 

3.4 Reasoning About Cyberforensic Cases and Forensic Lucid 

A Lucid dialect. Forensic Lucid 11211 |20l develops a specification of a cyber incident for analysis of 
claims of witnesses against encoded evidential statements to see if they agree or not and if they do 
provide potential backtraces of event reconstruction. The hierarchical context space similar to the one 
defined in the previous section is also used in Forensic Lucid to denote a context of a cybercrime case 
as a hierarchy consisting of the evidential statement es, that consists of observation sequences ("stories" 
told by evidence and witnesses) os, which in turn consist of observations o, that denote a certain observer 
property P and its duration [min,min + max], as shown in Figure [S] Forensic Lucid draws from an 
earlier formal approach using finite state automata by Gladyshev Q IH that is not very usable and all 
of the benefits of Lucid and intensional evaluation with functions and operators that navigate withing 
the higher-order context space of evidence and witness stories to evaluate claims. The Demptser-Shafer 
theory f9^, 35] is used to assigned weights, such as credibility and admissibility to witnesses evidence as 
a part of reasoning parameters. 
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Figure 6: Extract of Operational Semantics Rules of GIPL 



4 Conclusion 



We presented a modular intensional programming research platform, GIPSY, for reasoning tasks of 
HOIL expressions. The concept of context as a first-class value is central in the programming paradigms 
GIPSY is build to explore, such as a family of the Lucid programming languages. At the time of this 
writing GIPSY has support for compilation of GIPL, Indexical Lucid, Lucx, JLucid, and Objective Lucid 
and the execution of if the former two with the other being completed. The DMS for distributed transport 
of the demands has implementations in Jini, plain RMI, and JMS. 



4.1 Future Work 

The future and ongoing work within the context of GIPSY is a complete formalization of its hybrid 
intensional-imperative type system [.22 J . the revision of the syntax and semantics of the Forensic Lucid 
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E# 



c-tuple 



S'{id2) = (dim) 



^,3'^Ei.E2:tag{Eil{id2}) 



&,g'h {E,,E2,.. .,E„)E : v, fby.id V2 fby.id ... v„ fby.id eod 

£ = [d:v'] £' = (Ei,...,E„)d^' = .^t[rf^i''] S?,^'h£': 
select(E,E') : v 

^, ^ h ^ : ^ Sl,^^E:v 
E @C:v 

&,.0^hE@C:{vu...,v^} 

^ h : idj &(idj) = (dim) 
^, ^ h £, . : V, 3>' = .g^o t [idi ^vi]^...^[id„^ v„] 
S?, ^ h : ,£-d, : , . . . ,£rf„ : £,„] : ^' 

31, 3^ y- Ed, : idi &[idi) = (dim) 

{Ei,...,E„}= dim(3^i ) = ...= dim(ff'„) 
£" = f p(tag(^l), . . . , tag(^„,)) Si,.9>^E' ■ true 
9,ff>^Box[Ei,...,E„\E'\ : {.9>i, . . . , S",,,} 



^, ^ h £ : Si {id) = (cop, /) ^, ^ h Q : v,- 

S?,^h£'(Ci,...,C„):/(vi,...,v„) 

^,^h£:!rf 5^(!d) = (sop,/) ®,i?'hC,- : {v,,,...,v,J 
Sl,»^E(Cu-.-,Cn): /({v,, , . . . , V,, },..., {v„, , . . . , v„,„ }) 



(16) 
(17) 
(18) 
(19) 
(20) 
(21) 

(22) 

(23) 
(24) 
(25) 
(26) 



Figure 7: Extract of Operational Semantics of Lucx 




Observation Sequence (os) 



Evidential Statement (es) 




Observation Sequence (os) 




Observation Sequence (os) 



Figure 8: Nested Context Hierarchy Example for Cyberforensic Investigation 



language, and the multi-tier overhaul of the evaluation engine (GEE) including support for 00 inten- 
sional dialects. 
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